Options that impact performance

by Manu (modified: 2014 Jan 24)

Below we will see how the main options that control our code generation may impact your code. We will review the following:

  • exception trace (only has an impact in finalized mode, this option is always enabled in workbench mode)
  • multithreading
  • workbench vs. finalized

The results below are the time it took to compile the Eiffel compiler using the various code generation options on a 4+ years old computer using an Intel Xeon CPU E5420 at 2.50GHz:

Compilation mode Execution Time   Ratio
finalized, no exception trace, no multithreading 129s 1.0
finalized, exception trace, no multithreading184s 1.42 slower
finalized, exception trace, multithreading234s 1.81 slower

The same benchmark but this time compiling EiffelStudio:

Compilation mode Execution Time   Ratio
finalized, no exception trace, no multithreading 399s 1.0
finalized, exception trace, no multithreading 531s 1.33 slower
finalized, exception trace, multithreading 865s 2.04 slower

Finally we compare finalized vs workbench code generation against the compilation of EiffelStudio:

Compilation mode Execution Time   Ratio
finalized 865s 1.0
workbench 4944s 5.71 slower
new workbench code generation 4502s 5.02 slower

Note that in the workbench case, we have a new code generation we have been experimenting with and which gives us a good performance gain (about 5 to 9% on average in our own benchmarks). This optimization will be available in the next release of EiffelStudio 14.05.

As you can see keeping exception trace in finalized mode has an impact. Even if it makes things slower, EiffelStudio is compiled using this option so that whenever something bad happens, the automatic error reporting of EiffelStudio can send us as much details as possible on the failure.

Needless to say, that we will be working in the future to make those numbers look better by improving the overall performance when either or both of exception trace and multithreading (including SCOOP) are enabled.

There are other options that also have an impact on performance and that are not mentioned above:

  • Check for Void target: this option only makes sense in non-void-safe system and is enabled by default. If you disable it gain about 1-2% in performance.
  • Inlining and Inlinig Size: I definitely recommend enabling Inlining all the time. If you set the inlining size to 0, it will inline all empty routines and low level array access (features item and put of the SPECIAL class) without much impact on compilation time and some visible impact in execution time. If you set it to a larger number, then compilation time increases. On the Eiffel compiler, setting it to 8 slows down the compiler by 8% , but improve performance by about the same ration 8% and increase the executable size by about 7% .

Comments
  • Bernd Schoeller (11 years ago 24/1/2014)

    What is measured

    Hi Manu - it is not completely clear to me what you are measuring: the time it takes to compile the code with the features switched on (resuling in a binary with the features), or the time it takes a compiler with the features switched on to compile the code.

    The second would be more interesting to me than the first, because I want to know how my code behaves when I enable certain features, not how long it takes to compile.

    • Manu (11 years ago 24/1/2014)

      I'm comparing the different code generations and the time is the various results I get for the various code generations. It is no different than doing: 

      gcc -O0 foo.c -o foo ; time ./foo
gcc -O3 foo.c -o foo ; time ./foo

      In the particular case, foo' is either the Eiffel compiler or EiffelStudio, and foo.c' is the source code.

      I hope this clarifies things a little bit.

      • Bernd Schoeller (11 years ago 26/1/2014)

        OK - so you measuring the speed of the generated code, not the speed of the code generation. Thanks for the clarification.